Implementing changes for hardware, software, network, and storage systems in large-scale electronic business (e-business) environments is known to be quite burdensome to customers. Rolling out changes, such as installing or uninstalling, upgrading or configuring systems can take weeks, partly because the complex interdependencies between applications and their supporting services are not made explicit, thus requiring human involvement and expertise. Solving this change management problem automatically is important to address the increasing complexity of computing systems. The number of relationships of a single computing resource (for example, a software component, a network component, and/or a storage system) may range from 10 to 100. The number of computing resource instance relationships in large-scale enterprise systems is often between 1,000,000 and 1,000,000,000. Given that a change to one or more computing resources may entail additional changes on a multitude of other computing resources, it is evident that the need for human involvement in the change management process needs to be minimized.
Change management is a process that offers many automation challenges. The organizational frameworks behind existing change management processes tend to be ill-defined and highly variable in detail and formality. This makes it difficult to identify tasks for automation or to reuse standardized automation across environments within or between information technology (IT) organizations (a particular problem for corporate mergers). Additionally, effective change management requires a great deal of accurate information on technical constraints, such as dependencies between IT services, the components that implement them, and the infrastructure supporting them. This information is rarely documented formally or kept up-to-date, hindering change assessment and change impact prediction.
Existing approaches in the area of software development include U.S. Pat. No. 4,751,635, which includes a support system that provides data that reflects one or more aspects of a lifecycle of a development project, and U.S. Pat. No. 5,960,196, which includes generating a report to summarize computed metrics.
Existing approaches in the area of software maintenance include U.S. Pat. No. 5,493,682, which includes assembling executable systems from defined component parts such as source code files and object code files.
Existing approaches in the area of software packaging include U.S. Pat. No. 5,835,777, which includes a method of automatically generating a software installation package.
Techniques for electronic software distribution of whole program packages, such as U.S. Pat. No. 6,009,525, include methods of electronic software distribution in which software products may be wrapped by their publishers in a straightforward, secure manner, but in such a way as to allow for the addition of information by downstream distribution channel partners. Such techniques also include U.S. Pat. No. 5,721,824, which includes installation of a multi-package distribution software pack.
Techniques for updates, corrections, fixes and/or patches, such as U.S. Pat. No. 5,999,740, include a software update mechanism in the computer that accesses a remote file server to obtain a release file containing a list of software applications available from the remote server, and compares the release file with the registration file to determine which of the installed applications have upgrades available. Such techniques also include U.S. Pat. No. 5,805,891, which includes managing the maintenance of computer software by receiving a software maintenance module and verifying the validity of the software maintenance module.
Techniques for determining conflicts in existing software and/or hardware configurations, such as U.S. Pat. No. 5,867,714, include techniques for distributing configuration-dependent software revisions to a computer system.
Existing approaches to the computer resource change management problem often include individual software elements and modules that form the atomic parts of a program package and require the availability of program source code in order to build software and bundle it into software products. Source code is available to the software developer and not to the software user or system administrator. Furthermore, other existing approaches are, by definition, restricted to the distribution, deployment or installation of (one or many at a time) physical software packages and do not take the runtime stages of applications into account. In addition, such existing approaches include one system at a time and do not take the cross-system aspects of applications and services into account.
It would thus be desirable to overcome these and other limitations in computer resource change management approaches.